jira VULN-171934
cve CVE-2025-68366
commit-author Zheng Qixing <zhengqixing@huawei.com>
commit 1649714

There is one use-after-free warning when running NBD_CMD_CONNECT and
NBD_CLEAR_SOCK:

nbd_genl_connect
  nbd_alloc_and_init_config // config_refs=1
  nbd_start_device // config_refs=2
  set NBD_RT_HAS_CONFIG_REF			open nbd // config_refs=3
  recv_work done // config_refs=2
						NBD_CLEAR_SOCK // config_refs=1
						close nbd // config_refs=0
  refcount_inc -> uaf

------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290
 nbd_genl_connect+0x16d0/0x1ab0
 genl_family_rcv_msg_doit+0x1f3/0x310
 genl_rcv_msg+0x44a/0x790

The issue can be easily reproduced by adding a small delay before
refcount_inc(&nbd->config_refs) in nbd_genl_connect():

        mutex_unlock(&nbd->config_lock);
        if (!ret) {
                set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags);
+               printk("before sleep\n");
+               mdelay(5 * 1000);
+               printk("after sleep\n");
                refcount_inc(&nbd->config_refs);
                nbd_connect_reply(info, nbd->index);
        }

Fixes: e46c728 ("nbd: add a basic netlink interface")
	Signed-off-by: Zheng Qixing <zhengqixing@huawei.com>
	Reviewed-by: Yu Kuai <yukuai@fnnas.com>
	Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 1649714)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-174158
cve CVE-2025-71116
commit-author Ilya Dryomov <idryomov@gmail.com>
commit 8c73851

If the osdmap is (maliciously) corrupted such that the encoded length
of ceph_pg_pool envelope is less than what is expected for a particular
encoding version, out-of-bounds reads may ensue because the only bounds
check that is there is based on that length value.

This patch adds explicit bounds checks for each field that is decoded
or skipped.

	Cc: stable@vger.kernel.org
	Reported-by: ziming zhang <ezrakiez@gmail.com>
	Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
	Reviewed-by: Xiubo Li <xiubli@redhat.com>
	Tested-by: ziming zhang <ezrakiez@gmail.com>
(cherry picked from commit 8c73851)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-174768
cve CVE-2026-22984
commit-author ziming zhang <ezrakiez@gmail.com>
commit 818156c

Perform an explicit bounds check on payload_len to avoid a possible
out-of-bounds access in the callout.

[ idryomov: changelog ]

	Cc: stable@vger.kernel.org
	Signed-off-by: ziming zhang <ezrakiez@gmail.com>
	Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
	Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 818156c)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-174788
cve CVE-2026-22990
commit-author Ilya Dryomov <idryomov@gmail.com>
commit e00c3f7

If the osdmap is (maliciously) corrupted such that the incremental
osdmap epoch is different from what is expected, there is no need to
BUG.  Instead, just declare the incremental osdmap to be invalid.

	Cc: stable@vger.kernel.org
	Reported-by: ziming zhang <ezrakiez@gmail.com>
	Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit e00c3f7)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-176436
cve CVE-2026-23216
commit-author Maurizio Lombardi <mlombard@redhat.com>
commit 9411a89

In iscsit_dec_conn_usage_count(), the function calls complete() while
holding the conn->conn_usage_lock. As soon as complete() is invoked, the
waiter (such as iscsit_close_connection()) may wake up and proceed to free
the iscsit_conn structure.

If the waiter frees the memory before the current thread reaches
spin_unlock_bh(), it results in a KASAN slab-use-after-free as the function
attempts to release a lock within the already-freed connection structure.

Fix this by releasing the spinlock before calling complete().

	Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
	Reported-by: Zhaojuan Guo <zguo@redhat.com>
	Reviewed-by: Mike Christie <michael.christie@oracle.com>
Link: https://patch.msgid.link/20260112165352.138606-2-mlombard@redhat.com
	Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 9411a89)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-184557
cve CVE-2026-43190
commit-author Florian Westphal <fw@strlen.de>
commit 735ee85

Quoting reporter:
  In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads
 op[i+1] directly without validating the remaining option length.

  If the last byte of the option field is not EOL/NOP (0/1), the code attempts
  to index op[i+1]. In the case where i + 1 == optlen, this causes an
  out-of-bounds read, accessing memory past the optlen boundary
  (either reading beyond the stack buffer _opt or the
  following payload).

	Reported-by: sungzii <sungzii@pm.me>
	Signed-off-by: Florian Westphal <fw@strlen.de>
(cherry picked from commit 735ee85)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>

jira VULN-184487
cve CVE-2026-43158
commit-author Darrick J. Wong <djwong@kernel.org>
commit 3eefc0c

xfs/592 and xfs/794 both trip this assertion in the leaf block freemap
adjustment code after ~20 minutes of running on my test VMs:

 ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t)
					+ xfs_attr3_leaf_hdr_size(leaf));

Upon enabling quite a lot more debugging code, I narrowed this down to
fsstress trying to set a local extended attribute with namelen=3 and
valuelen=71.  This results in an entry size of 80 bytes.

At the start of xfs_attr3_leaf_add_work, the freemap looks like this:

i 0 base 448 size 0 rhs 448 count 46
i 1 base 388 size 132 rhs 448 count 46
i 2 base 2120 size 4 rhs 448 count 46
firstused = 520

where "rhs" is the first byte past the end of the leaf entry array.
This is inconsistent -- the entries array ends at byte 448, but
freemap[1] says there's free space starting at byte 388!

By the end of the function, the freemap is in worse shape:

i 0 base 456 size 0 rhs 456 count 47
i 1 base 388 size 52 rhs 456 count 47
i 2 base 2120 size 4 rhs 456 count 47
firstused = 440

Important note: 388 is not aligned with the entries array element size
of 8 bytes.

Based on the incorrect freemap, the name area starts at byte 440, which
is below the end of the entries array!  That's why the assertion
triggers and the filesystem shuts down.

How did we end up here?  First, recall from the previous patch that the
freemap array in an xattr leaf block is not intended to be a
comprehensive map of all free space in the leaf block.  In other words,
it's perfectly legal to have a leaf block with:

 * 376 bytes in use by the entries array
 * freemap[0] has [base = 376, size = 8]
 * freemap[1] has [base = 388, size = 1500]
 * the space between 376 and 388 is free, but the freemap stopped
   tracking that some time ago

If we add one xattr, the entries array grows to 384 bytes, and
freemap[0] becomes [base = 384, size = 0].  So far, so good.  But if we
add a second xattr, the entries array grows to 392 bytes, and freemap[0]
gets pushed up to [base = 392, size = 0].  This is bad, because
freemap[1] hasn't been updated, and now the entries array and the free
space claim the same space.

The fix here is to adjust all freemap entries so that none of them
collide with the entries array.  Note that this fix relies on commit
2a2b593 ("xfs: fix attr leaf header freemap.size underflow") and
the previous patch that resets zero length freemap entries to have
base = 0.

	Cc: <stable@vger.kernel.org> # v2.6.12
Fixes: 1da177e ("Linux-2.6.12-rc2")
	Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
	Reviewed-by: Christoph Hellwig <hch@lst.de>
(cherry picked from commit 3eefc0c)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>